The techniques described in this section are techniques that could be pursued, but not necessarily techniques that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the techniques described in this section qualify as prior art merely by virtue of their inclusion in this section.
Some telecommunications networks employ a form of address translation known as Network Address Translation (NAT) at devices that serve as the gateway between the networks and the Internet. There are two primary implementations of NAT. The first implementation, dynamic address NAT, assigns a temporary global IP address to local IP addresses for nodes within the network separated from the Internet by the NAT device. Generally, for the nodes within the network, a different temporary global IP address is used for each node. With dynamic address NAT, addresses are only used for a connection as long as the connection is alive. When the connection is terminated the addresses are available for use in subsequent connections. Note that global IP addresses may be referred to as external or public IP addresses, and local IP addresses may be referred to as internal or private IP addresses.
The second implementation, Network Address Port Translation (NAPT), allows a network to essentially hide behind a single public, or global, IP address. While each node within a network using NAT at the gateway separating the network and the Internet has a unique local IP address, traffic exiting the network through the gateway uses the global IP address. A translation table is used by the gateway to associate the local addresses with the global address.
The term “NAT” will be used herein to refer to network address translation that encompasses both dynamic address NAT and NAPT.
When a network uses NAT, the traffic that passes out of the network through gateway to the Internet does not include the true local IP address of the nodes within the network. When traffic directed to the nodes within the network is received from outside of the network by the gateway, the traffic is addressed to the global address assigned by the gateway device. When out of network traffic is received, the gateway device uses the translation table to look up which local address corresponds to the global address of the incoming traffic to the properly direct the traffic within the network. For example, some Internet service providers (ISPs) use a NAT device as a gateway between the ISP's network and the Internet. Use of NAT is common among ISP's providing Digital Subscriber Line (DSL) and cable access that have numerous customers within the ISP's networks.
Some telecommunications networks secure traffic over networks through the use of the Internet Protocol Security (IPsec or IPSec), which may be used with a virtual private network (VPN). IPsec uses security associations (SA's) that specify the parameters for the IPsec secured traffic, and IPsec operates in one of two modes, transport mode or tunnel mode, using one of two protocols, Encapsulating Security Payload (ESP) or Authentication Header (AH). A transport mode security association is an SA between two hosts. A transport mode security protocol header (either ESP or AH) appears immediately after the IP header and before any higher layer protocols (e.g., transmission control protocol (TCP) or user datagram protocol (UDP)). A tunnel mode security association is an SA that is applied to an IP tunnel. Whenever either end of a security association is a security gateway, the SA is a tunnel mode SA. For a tunnel mode SA, there is an “outer” IP header that specifies the IPsec processing destination, and there is an “inner” IP header that specifies the “apparent” ultimate destination for the packet. The ultimate destination may be “apparent” and not the actual ultimate destination, such as due to the use of NAT device.
Furthermore, there are two protocols used with IPsec. For both transport and tunnel mode, the Encapsulating Security Payload (ESP) protocol secures data that follows the ESP header, and thus ESP does not secure the IP header that is before the ESP header. For both transport and tunnel mode, the Authentication Header (AH) secures both data that follows the AH header and the IP header that is before the AH header.
IPsec uses Security Parameter Index (SPI) values to identify the security association (SA) used for the secured traffic between two nodes, such as over a VPN. The SA defines the encryption protocols, keys, and other parameters relating to the IPsec secured traffic. Conventionally, the SPI for each node communicating via IPsec is a randomly generated value having a length of four bytes. As used herein, the node initiating an IPsec based communication is referred to as the “IPsec originator node,” and the node responding to the communication is referred to as the “IPsec responder node.”
The SPI for each node is determined during the second phase of the Internet Key Exchange (IKE) portion of the IPsec protocol as the SA is negotiated between the IPsec originator node and the IPsec responder node. Because the SA negotiation is encrypted, the NAT device does not know the SPI's for each node.
A problem arises when IPsec secured traffic passes through a device that employs NAT because with some IPsec modes and protocols, the change in the IP addresses by the NAT device causes the IPsec security checks to fail. For example, the AH protocol uses the IP address to ensure the authenticity (e.g., origin) of the traffic by encapsulating the IP address, so that changing the IP address for traffic passing through the NAT device will lead to a security violation. As another example, transport mode also protects the IP address, so that a change in the IP address by the NAT device will also lead to a security violation.
IPsec traffic using the ESP protocol, either in transport mode or in tunnel mode, will not have the IP headers protected, and therefore security violations do not occur as a result of the NAT device changing the IP address. However, a problem arises with IPsec using the ESP protocol in tunnel mode when more than one node within the network protected by the gateway employing NAT wants to use IPsec with the same outside node. The problem is of particular concern if the gateway employs NAPT that which uses the same inside global IP address for all of the local nodes inside the network.
FIG. 1 depicts a logical block diagram 100 with two IPsec originator nodes within a network separated from the Internet by a NAT device, where the two IPsec originators both attempt to establish IPsec based communications with the same IPsec responder node. In FIG. 1, IPsec originator nodes 110, 120 are communicatively coupled to ISP network 130, which in turn is communicatively coupled to Internet 150 via an ISP NAT device 140. An IPsec responder node 160 is communicatively coupled to Internet 150.
Assume that ISP NAT device 140 employs NAPT in which a common global IP address is used for all nodes within ISP network 130. When IPsec originator node 110 sends IPsec traffic to IPsec responder node 160, ISP NAT device 140 replaces the local IP address for IPsec originator node 110 with a global IP address for ISP network 130. When IPsec responder node 160 receives the IPsec traffic from IPsec originator node 110, IPsec responder node 160 only knows the global address for ISP network 130, and the response sent by IPsec responder node 160 to IPsec originator node 110 will be sent to the global IP address for ISP network 130. When the traffic from IPsec responder node 160 is received by ISP NAT device 140, ISP NAT device 140 does not know whether to send the IPsec traffic to IPsec originator node 110 or IPsec originator node 120 because the traffic is address to the global address for ISP network 130.
However, ISP NAT device 140 conventionally is configured with a default approach for handling this type of situation. Assume for this example that ISP NAT device 140 is configured to forward the incoming IPsec traffic to the IPsec originator node that most recently sent IPsec traffic from ISP network 130.
The problem arises when IPsec originator node 120 also wants to initiate an IPsec secured connection with IPsec responder node 160 before the connection between IPsec originator node 110 and IPsec responder node 160 is established. In this situation, both IPsec originator node 110 and IPsec originator node 120 have initiated IPsec connections with IPsec responder node 160. Assume for this example that IPsec originator node 110 sent the first request to IPsec responder node 160, followed shortly thereafter by IPsec originator node 120.
When IPsec responder node 160 replies to the first request received from IPsec originator nodes 110, 120, ISP NAT device 140 follows the default approach and forwards the incoming IPsec traffic to the last IPsec originator node that sent IPsec traffic from ISP network 130. Assume for this example that the first request received by IPsec responder node 160 is from IPsec originator node 110. However, as assumed above, the last IPsec traffic passing out of the ISP's system was from IPsec originator node 120. Therefore, by following the conventional default approach, ISP NAT device 140 will forward the IPsec traffic to IPsec originator node 120, which is incorrect.
Even if other default approaches for forwarding IPsec traffic are used by ISP NAT device 140, such as forwarding the incoming IPsec traffic to the node that first sent out IPsec traffic, there will be times when the default approach results in forwarding the IPsec traffic to the wrong IPsec originator node. For example, even under this altered default approach, the order that the IPsec originators send traffic through ISP NAT device 140 does not guarantee that responses from IPsec responder node will be received in the same order due to variations in response times by IPsec responder node 160 and transmission times through Internet 150.
One approach for solving this problem is to prevent more than one originator node from trying to establish an IPsec connection with a particular IPsec responder node at the same time. For example, if IPsec originator node 110 sends IPsec traffic to IPsec responder node 160, IPsec originator node 120 is prevented by ISP NAT device 140 from sending an IPsec based request to IPsec responder node 160 until either the IPsec based connection between IPsec originator node 110 and IPsec responder node 160 is established or the attempt to establish the IPsec based connection is timed out. Once the IPsec based connection is established, ISP NAT device 140 can associate the SPI used by IPsec originator node 110 with the SPI used by IPsec responder node 160 for the IPsec based connection to ensure that incoming IPsec traffic is directed to the proper IPsec originator node. After the connection between IPsec originator node 110 and IPsec responder node 160 is established, ISP NAT device 140 allows IPsec originator node 120 to send IPsec traffic to IPsec responder node 160. This approach may be referred to as “serialization.”
There are several drawbacks to serialization, such as the delay associated with IPsec originator nodes having to wait to for other IPsec originator nodes to first establish IPsec connections. The wait can be significant if there are many IPsec originator nodes trying to connect to the same IPsec responder node. Furthermore, IPsec connections use timeouts and require a new SA to be established upon expiration of a timeout. The shorter the timeout, the more often the IPsec connections need to be re-established, increasing the chances that two or more IPsec originator nodes will be trying to establish an IPsec connection at the same time.
Another approach for handling multiple IPsec communications through a NAT device is to pass the IPsec traffic through the NAT device using transmission control protocol/user datagram protocol (TCP/UDP) encapsulation of the IPsec ESP packets. Because the NAT device only alters the IP addresses in the outer TCP/UDP encapsulation headers, the IPsec headers remain unchanged. However, the extra TCP/UDP encapsulation results in additional overhead, sometimes of up to 28 bytes.
Further, the Internet Key Exchange (IKE) part of the IPsec protocol needs to detect the presence of the NAT device to know when the TCP/UDP encapsulation is needed, otherwise the extra overhead is incurred even when a NAT device is not present to cause a problem. Also, “keepalives” need to be used to keep the NAT translation active because the UDP encapsulation often involves aggressive timeouts on the order of a few minutes, and while keepalives are not needed for TCP encapsulation, undesirable retransmissions may occur.
Yet another approach is to use Realm Specific IP (RSIP) so that the IPsec originator nodes can communicate with the NAT device to perform the address translation. While this precludes the need to change the IKE protocol of IPsec, the IPsec processing must be altered to be compatible with the RSIP approach, which would involve changes to both the IPsec originator node and the NAT device. While a network owner, such as an ISP, may be able to absorb the expense of modifying the NAT devices, making alterations to the IPsec originator nodes that are typically owned by the ISP's customers is often not practical.
Based on the foregoing, it is desirable to provide improved techniques for facilitating IPsec communications through devices that employ address translation in a telecommunications network.